Apéndice C · PRD
Alcance de la Prueba de Concepto
0 Contexto y resumen ejecutivo
Por qué el cotizador va primero
- Es el dolor prioritario declarado. NetPay fue explícito: el problema hoy no es la rentabilidad, es la velocidad de ejecución. El cuello de botella son ~35 campos y un prospecto obligatorio antes de poder cotizar; el asesor en la calle solo quiere un rango con el que salir a negociar.
- Dos terceras partes de la originación pasan por el simulador. Es la superficie de mayor impacto del proceso completo, y la primera interacción de todo el journey: sin cotización no hay caso.
- Es demostrable sin integraciones. El cálculo es determinístico (fórmulas del simulador); se puede validar con casos de referencia sin tocar sistemas productivos, lo que hace viable la fecha de fin de agosto.
La POC es un agente AI en WhatsApp (teléfono normal, sin WhatsApp Business) que ejecuta un solo use case: la precotización light — el check rápido que da al asesor un rango negociable antes de registrar al cliente. Calcula con las 6 variables formales replicando el modelo real del simulador, clasifica el resultado dentro/fuera de parámetros y escala a un humano vía dashboard cuando corresponde.
Incluye KB dinámica con training mode, carga de documentos con OCR y validación básica, motor de cotización centralizado accesible por API, y un dashboard operativo para la mesa de control documental. Full functional, sin integración a terceros, corriendo en el entorno de demostración de DashOne; la arquitectura hexagonal permite migrar a la infraestructura del cliente en Fase 2 sin tocar el dominio. Objetivo: demostrar funcionalidad y factibilidad técnica express, para fin de agosto de 2026.
1 Cotizador completo vs. cotizador light
Existen dos alcances del cotizador. Está acordado con NetPay que la POC va sobre la versión light.
Check rápido de precotización, sin tipo de originación y sin registro previo del cliente. Da al Socio Comercial un rango con el que salir a negociar. Calcula con las 6 variables formales y el modelo real del simulador.
Cotización formal por tipo de originación (client, company, multi-RFC, branch, store), atada al registro del prospecto, la estructura company/branch/store y la cadena de auditoría hacia los sistemas de NetPay.
2 Usuarios finales
| Usuario | Rol en la POC | Superficie |
|---|---|---|
| Asesores comerciales | Conversan con el agente, precotizan y cargan documentos. | |
| Mesa de control documental | Revisa y valida manualmente los documentos cargados; resuelve escalamientos HITL. | Dashboard operativo (web) |
| Admin | Configura el agente, edita la KB y opera el training mode; da de alta usuarios y permisos. | Dashboard operativo (web) |
3 Alcance de la POC — componentes
| # | Componente | Alcance en la POC |
|---|---|---|
| 1 | Agente AI en WhatsApp | Identidad definida, knowledge base, skills básicos, connectors básicos y guardrails para mantenerlo compliant. |
| 2 | KB dinámica + training mode | Marcar respuestas buenas/malas y editar el contenido de la KB desde el dashboard. |
| 3 | Infraestructura | Entorno de demostración DashOne para lift-up rápido. En Fase 2 apunta a la infraestructura del cliente (Sección 7). |
| 4 | Funcionalidad completa sin terceros | Full functional, sin integración a sistemas de terceros (Salesforce, Nufi, Mifiel, Core). |
| 5 | Dashboard operativo | Monitoreo de mensajes y control del agente: conversaciones, escalamientos, revisión documental, KB y training mode. |
| 6 | Canal WhatsApp estándar | Teléfono de WhatsApp normal; no requiere WhatsApp Business. |
| 7 | Notificaciones básicas | TBD Alcance y eventos por definir con NetPay. |
| 8 | Un solo flow / use case | Precotización light sin tipo de originación — el check rápido antes de registrar al cliente. |
Nice-to-have
Deseables dentro de la POC. Se construyen si el avance del alcance base lo permite. Los criterios de aceptación que dependen de ellos — CA-03 (HITL), CA-04 (OCR) y CA-06 (motor por API) — solo aplican si el componente se construye. Las secciones 4 y 5 los describen a detalle bajo esa misma condición.
| # | Componente | Alcance en la POC |
|---|---|---|
| NTH-01 | HITL y políticas de escalamiento | Human-in-the-loop con políticas definidas; el humano opera desde el dashboard (Sección 4). |
| NTH-02 | Motor de cotización centralizado | Lógica del cotizador desacoplada del canal, accesible por API. Exposición vía MCP: TBD |
| NTH-03 | Carga de documentos + OCR | Carga por WhatsApp, OCR y validación básica de formato y tipo. Set corto (~3–4 documentos típicos del flujo). Validación de fondo: humana, en la mesa de control. |
| NTH-04 | Repositorio de documentos | Object storage donde queda lo cargado por WhatsApp, disponible en el dashboard para revisión y validación manual. |
4 HITL y escalamiento
- Disparadores: cotización fuera de parámetros, documento que no pasa la validación de formato/tipo, o solicitud del asesor que el agente no puede resolver dentro de sus guardrails.
- Canal del revisor: exclusivamente el dashboard operativo (web). El asesor recibe la resolución de vuelta en WhatsApp.
- El agente nunca aprueba excepciones: clasifica, escala y notifica; la decisión es humana.
- Trazabilidad: todo escalamiento queda registrado con conversación, datos capturados y resolución.
5 Variables y cálculo
El cotizador light de la POC calcula con las 6 variables formales completas confirmadas por NetPay, replicando el modelo real del simulador:
- Facturación mensual
- Ticket promedio
- Tipo de terminales (A910S · IM30 · Aries 8 · M1 · UROVO · P8 Dual)
- Distribución de volumen (6 tramos: débito, crédito, internacional, AmEx, MSI PROSA/eGlobal, MSI AmEx)
- Familia
- Giro (natural · agregador)
Los campos con valor típico en 98–99% de los casos se prellenan como sugerencia editable, para acercarse al objetivo de "cinco preguntas esenciales".
6 Fuera de alcance
- Tiempo de entrenamiento del agente o del equipo.
- Edge cases del proceso o del cálculo.
- Transcripción de audio, interpretación de emojis y video.
- Integraciones a sistemas de terceros (Salesforce, Nufi, Mifiel, Core) y datos productivos.
- Flujos adicionales al único use case definido.
7 Arquitectura y Fase 2
Arquitectura hexagonal, agnóstica al stack. El naming de componentes y variables se desacopla de la tecnología hasta donde sea práctico: se nombra la capacidad, no el proveedor — database en lugar del motor específico, object storage en lugar del servicio de archivos, function en lugar del producto serverless. El nombre del vendor solo se usa cuando omitirlo complica el trabajo del equipo de desarrollo o del coding agent.
Corre en el entorno de demostración de DashOne para un lift-up rápido, sin depender de accesos ni provisioning del cliente. No procesa datos productivos.
Migración a AWS y Bedrock dentro del entorno del cliente. La arquitectura hexagonal hace el swap de adaptadores seamless: cambia la infraestructura, no el dominio.
8 Criterios de aceptación
| CA | Criterio |
|---|---|
| CA-01 | El asesor completa una precotización de punta a punta dentro de WhatsApp, sin registro previo del cliente. |
| CA-02 | El cálculo reproduce el modelo del simulador sobre casos de referencia acordados con NetPay (entrada → resultado esperado). |
| CA-03 | Un caso fuera de parámetros escala a HITL, se resuelve en el dashboard y la resolución regresa al asesor en WhatsApp. |
| CA-04 | Un documento cargado por WhatsApp pasa OCR y validación de formato/tipo, y queda disponible en el repositorio para revisión humana. |
| CA-05 | El equipo NetPay observa el training mode: marcar una respuesta como buena/mala y editar la KB con efecto en la siguiente conversación. |
| CA-06 | El motor de cotización responde por API de forma independiente del canal de WhatsApp. |
Flujo e interacción con el agente y los sistemas
User journey, componentes y puntos de integración futura
9 Preguntas abiertas
| Q | Pregunta | Por qué importa |
|---|---|---|
| Q-01 | ¿Cómo se debe ver el resultado de la cotización? ¿La salida estilo simulador (rango mínimo/sugerido) es suficiente, o requiere otra presentación para el asesor (carta preliminar, resumen negociable, formato visual)? | Define el entregable final del journey y cómo el asesor lo usa frente al comercio. |
| Q-02 | ¿En qué puntos del journey el asesor puede cambiar o "jugar" con los valores y qué comportamiento debe tener el agente ante ello: permitir ajuste libre dentro de un rango seguro, registrar cada cambio, o limitar los reintentos? | Es el punto exacto donde hoy ocurre la manipulación de variables (gaming del cotizador). La POC no debe reproducir ese dolor ni dejarlo sin trazabilidad. |
10 Calendario
- Fecha objetivo: antes de que finalice agosto de 2026.
- Tolerancia: primera semana de septiembre de 2026.
- Evaluación: demo con el equipo NetPay de la sesión (~5–8 personas); el resultado alimenta su comité interno.